-
-
Notifications
You must be signed in to change notification settings - Fork 33.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Further improve Vue type declarations for canonical usage #6391
Conversation
… as members from 'data' and the Vue instance.
…Vue instance members.
…s, got rid of AnyVue.
Conflicts: types/vue.d.ts
Conflicts: types/options.d.ts types/test/options-test.ts types/test/vue-test.ts types/vue.d.ts
Conflicts: package.json
* build(release weex): ignore the file path of entries * [release] weex-vue-framework@2.4.2-weex.1
Conflicts: types/vue.d.ts
Simplify 'CreateElement', remove potential error in 'AsyncComponent' …
@HerringtonDarkholme are you on slack? Can you give an email address so I can invite you to the team slack? (maybe via Twitter DM) |
I drafted a blog post regarding the 2.5 TS upgrade, feedback needed! https://medium.com/the-vue-point/upcoming-typescript-changes-in-vue-2-5-e9bd7e2ecf08 |
@yyx990803, looks good, two typos:
|
@robert-claypool thanks, fixed. |
@yyx990803 I'm already on slack! |
I will try to give some deeper feedback later, but
|
extend<PropNames extends string = never>(definition: FunctionalComponentOptions<Record<PropNames, any>, PropNames[]>): ExtendedVue<V, {}, {}, {}, Record<PropNames, any>>; | ||
extend<Props>(definition: FunctionalComponentOptions<Props, RecordPropsDefinition<Props>>): ExtendedVue<V, {}, {}, {}, Props>; | ||
extend<Data, Methods, Computed, PropNames extends string>(options?: ThisTypedComponentOptionsWithArrayProps<V, Data, Methods, Computed, PropNames>): ExtendedVue<V, Data, Methods, Computed, Record<PropNames, any>>; | ||
extend<Data, Methods, Computed, Props>(options?: ThisTypedComponentOptionsWithRecordProps<V, Data, Methods, Computed, Props>): ExtendedVue<V, Data, Methods, Computed, Props>; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Having tried this out, while Props
inference is great, I think there will be cases where someone will want to write an interface
for props
and then let Data
, Methods
, and Computed
be inferred on their own, and then let
Maybe we should reorder this so that Props
comes first? something like
extend<Props = Record<PropNames, any>, PropNames extends string = never, Data = {}, Methods = {}, Computed = {}>(options?: ThisTypedComponentOptionsWithArrayProps<V, Data, Methods, Computed, PropNames>): ExtendedVue<V, Data, Methods, Computed, Props>;
extend<Props = {}, Data = {}, Methods = {}, Computed = {}>(options?: ThisTypedComponentOptionsWithRecordProps<V, Data, Methods, Computed, Props>): ExtendedVue<V, Data, Methods, Computed, Props>;
What do you think @HerringtonDarkholme?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if inferring default generic parameter is available in current TS. microsoft/TypeScript#14400 or this comment microsoft/TypeScript#13487 (comment)
So users have to annotate all the type parameters as long as they want to specify at least one parameter.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unfortunately we haven't yet implemented that. This isn't a blocker though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm merging this in preparation for 2.5 release. We can improve upon this in a separate PR later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We were using this pattern below
interface AppComponent extends Store, Vue {
// Additional typed props besides ones defined on Store here
}
export default {
// ...
} as ComponentOptions<AppComponent>
but it looks like this isn't possible with Vue 2.5 no more. Is there another way to type your props now? Possible workaround is to wrap props inside computed property with added type, but this isn't really elegant.
@yyx990803 @HerringtonDarkholme @DanielRosenwasser any changes to Vue typings due to TS 2.6 release? |
@eshimischi if you're having any specific problems with the type declarations given TypeScript 2.6, I'd suggest you file a separate issue. |
This pull request supersedes #5887 .
Key improvements:
@ktsn @kaorun343 @DanielRosenwasser Your reviews or suggestions are welcome!
This section provides more background for other reviewers/readers.
Vue + TS users currently need helper library like vue-component-class to provide alternative API for TypeScript. Alternative API uses code pattern that TypeScript recognizes, but it splits Vue community.
Thankfully, TypeScript introduces ThisType which can greatly improve Vue's canonical API. This PR introduces ThisType to Vue's official typing.
More importantly, this improvement also benefits JavaScript users! VSCode users or Vue-language-server users exploits TypeScript compiler to provide editor services for JavaScript. Thus the typing improvement can help JavaScript completion more intelligent.
Goal:
Non Goal:
Known limitations:
new Vue()
wouldn't return a type with props type. This is caused by compiler limitations.oneProp: [String, User]
might not work without manual annotation.Next step:
Since we already has a canonical Vue API in TS, next we can ship tsx support in the official repo.